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Introduction 


Multi-Topology (MT) routing is supported in IP networks with the use 


of MT-aware IGPs. It would be advantageous for Communications 
Service Providers (CSPs) to support an MPLS Multi-Topology (MPLS-MT) 
environment. The benefits of MPLS-MT technology are features for 


various network scenarios, including: 


o A CSP may want to assign varying Quality of Service (QoS) profiles 
to different traffic classes, based on a specific topology in an 
MT routing network; 


o Separate routing and MPLS domains may be used to isolate multicast 
and IPv6 islands within the backbone network; 


o Specific IP address space could be routed across an MT based on 
security or operational isolation requirements; 


o Low-latency links could be assigned to an MT for delay-sensitive 
traffic; 


o Management traffic may be divided from customer traffic using 
different MTs utilizing separate links, thus ensuring that 
management traffic is separated from customer traffic. 


This document describes the Label Distribution Protocol (LDP) 
procedures and protocol extensions required to support MT routing in 


an MPLS environment. 


This document defines two new Forwarding Equivalence Class (FEC) 
types for use in Label Switched Path (LSP) ping [RFC4379]. 


Terminology 


This document uses MPLS terminology defined in [RFC5036]. Additional 
terms are defined below: 


o MT-ID: A 16-bit value used to represent the Multi-Topology ID. 


o Default MT Topology: A topology that is built using the MT-ID 
default value of 0. 


o MT Topology: A topology that is built using the corresponding MT- 
ID. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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Signaling Extensions 
1.  Topology-Scoped Forwarding Equivalence Class (FEC) 


LDP assigns and binds a label to a FEC, where a FEC is a list of one 
or more FEC elements. To set up LSPs for unicast IP routing paths, 
LDP assigns local labels for IP prefixes and advertises these labels 
to its peers so that an LSP is set up along the routing path. To set 
up MT LSPs for IP prefixes under a given topology scope, the LDP 
prefix-related FEC element must be extended to include topology 
information. This implies that the MT-ID becomes an attribute of the 
prefix-related FEC element, and all FEC-Label binding operations are 
performed under the context of a given topology (MT-ID). 


The following section ("New Address Families: MT IP") defines the 
extension required to bind the prefix-related FEC to a topology. 


.2. New Address Families: MT IP 


Section 2.1 of the LDP base specification [RFC5036] defines the 
Address Prefix FEC element. The Prefix encoding is defined for a 
given "Address Family" (AF), and has length (in bits) specified by 
the "PreLen" field. 


To extend IP address families for MT, two new Address Families named 
"MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 
within a topology scope. 


The format of data associated with these new Address Families is 
described below: 


0 1 2 3 

0 Ll 2-3.4 5 6 T7 .8:9-0 1.2.3.4 5 6.7 8 9 0 12 3-4 5 6 T 8.9 0. 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ — o o + + + 
| IPv4 Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ — — o o + + 
| Reserved | MT-ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 


Figure 1: MT IP Address Family Format 
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0 £ 2 3 
OL 2-354 56 y 8 9 0.1 2 3 4 5-6 7.8 9 0 12 34-96: 7 8 9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O O O A AO A —— o o + + 
| IPv6 Address | 
| | 
Le ee Rae A ROME NRI ee eee ee 
| Reserved | MT-ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


Figure 2: MT IPv6 Address Family Format 


Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 
"MT IPv6" AF respectively, and the field "MT-ID" corresponds to the 
16-bit Topology ID for a given address. 


The definition and usage for the remaining fields in the FEC elements 
are as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 
the default topology and MUST be ignored on receipt so as to not 
cause any conflict/confusion with existing non-MT procedures. 


The defined FEC elements with "MT IP" Address Family can be used in 


any LDP message and procedures that currently specify and allow the 
use of FEC elements with IP/IPv6 Address Family. 


3.3. LDP FEC Elements with MT IP AF 
The following section specifies the format extensions of the existing 
LDP FEC elements to support MT. The "Address Family" of these FEC 
elements will be set to "MT IP" or "MT IPv6". 


The MT Prefix FEC element encoding is as follows: 


0 1 2 3 
0 L.2 $34 5.6 :8:9-0.1 2 3.4.5.6 7.8. 9/0 L2 34 eT Bi OO! 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Prefix (2) | Address Family (MT IP/MT IPv6) | PreLen | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Prefix | 


"———————————————————————————————————————————— 
Reserved MT-ID | 
"——————————————————————————————————————— Ht 


+—+ 


Figure 3: MT Prefix FEC Element Format 
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The MI Typed Wildcard FEC element encoding is as follows: 


0 ii 2 3 
0 I.2- 3-4 567.89 0 T-2734 5 6789 0123-45678 90 1 


|... or MT IPv6 | MT-ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Typed Wcard (5) | FEC Type | Len = 6 | AF = MT IP | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 4: MT Typed Wildcard FEC Element 


The above format can be used for any LDP FEC element that allows use 
of the IP/IPv6 Address Family. In the scope of this document, the 
allowed "FEC Type" in a MT Typed Wildcard FEC element is the Prefix 
FEC element. 


3.4. IGP MT-ID Mapping and Translation 


The non-reserved non-special IGP MT-ID values can be used and carried 
in LDP without the need for translation. However, there is a need 
for translating reserved or special IGP MT-ID values to corresponding 
LDP MT-IDs. The assigned, unassigned, and special LDP MT-ID values 
have been assigned as described in Section 9 ("IANA Considerations"). 


How future LDP MT-ID values are allocated is outside the scope of 


this document. Instead, a separate document will be created to 
detail the allocation policy and process for requesting new MT-ID 
values. 


3.5. LDP MT Capability Advertisement 
3.5.1. Protocol Extension 


We specify a new LDP capability, named "Multi-Topology (MT)", which 
is defined in accordance with the LDP capability guidelines 
[RFC5561]. The LDP "MT" capability can be advertised by an LDP 
speaker to its peers either during the LDP session initialization or 
after the LDP session is set up. The advertisement is to announce 
the capability of the Label Switching Router (LSR) to support MT for 
the given IP address family. An LDP speaker MUST NOT send messages 
containing MT FEC elements unless the peer has said it can handle it. 


The MT capability is specified using the Multi-Topology Capability 


TLV. The Multi-Topology Capability TLV format is in accordance with 
the LDP capability guidelines as defined in [RFC5561]. To be able to 
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Specify IP address family, the capability-specific data (i.e., the 
"Capability Data" field of Capability TLV) is populated using the 
"Typed Wildcard FEC element" as defined in [RFC5918]. 


The format of the Multi-Topology Capability TLV is as follows: 


0 1 2 3 

0 1. 2:3.4 5.6 58 9/0 1.2.3.5 6 7-8: 9-0 1:23. 4 5-6 7 8.9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
pole] Multi-Topology Cap. (IANA) | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|S| Reserved | | 
€————— ÀÀ | 
^ Typed Wildcard FEC element (s) y 


Pod + + O de hd dd $ $ q — $ + q — dd q + 4 + ++ +++ +++ +++ 
Figure 5: Multi-Topology Capability TLV Format 
Where: 


o U-bit: MUST be 1 so that the TLV will be silently ignored by a 
recipient if it is unknown, according to the rules of [RFC5036]. 


o F-bit: MUST be 0 as per Section 3 ("Specifying Capabilities in LDP 
Messages") of LDP Capabilities [RFC5561]. 


o Multi-Topology Capability: Capability TLV type (IANA assigned) 


o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 
set to 0 or 1 in dynamic "Capability" message to advertise or 
withdraw the capability, respectively. 


o Typed Wildcard FEC element(s): One or more elements specified as 
the "Capability data". 


o Length: length of Value field, starting from the S-bit, in octets. 


o The encoding of the Typed Wildcard FEC element, as defined in 
[RFC5918], is defined in Section 4.1 ("Typed Wildcard FEC 
element") of this document. The MT-ID field of the MT Typed 
Wildcard FEC element MUST be set to "Wildcard Topology" when it is 
specified in the MT Capability TLV. 
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3.5.2. Procedures 


To announce its MT capability for an IP address family, LDP FEC type, 
and Multi-Topology, an LDP speaker sends an "MT Capability" including 
the exact Typed Wildcard FEC element with the corresponding 
"AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT 
IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., 
set to "Prefix"), and corresponding "MT-ID". To announce its MT 
capability for both the IPv4 and IPv6 address family, or for multiple 
FEC types, or for multiple Multi-Topologies, an LDP speaker sends an 
"MT Capability" with one or more MT Typed FEC elements in it. 


o The capability for supporting multi-topology in LDP can be 
advertised during LDP session initialization stage by including 
the LDP MT capability TLV in LDP Initialization message. After an 
LDP session is established, the MT capability can also be 
advertised or withdrawn using the Capability message (only if the 
"Dynamic Capability Announcement" capability [RFC5561] has already 
been successfully negotiated). 


o If an LSR has not advertised MT capability, its peer MUST NOT send 
to this LSR any LDP messages with FEC elements that include an MT 
identifier. 


o If an LSR is changed from non-MT capable to MT capable, it sets 
the S-bit in the MT capability TLV and advertises via the 
Capability message (if it supports Dynamic Capability 
Announcement). The existing LSP is treated as an LSP for default 
MT (ID 0). 


o If an LSR is changed from LDP-MT capable to non-MT capable, it 
initiates withdrawal of all label mapping for existing LSPs of all 
non-default MTs. It also cleans up all the LSPs of all non- 
default MTs locally. Then, it clears the S-bit in the MT 
capability TLV and advertises via the Capability message (if it 
supports Dynamic Capability Announcement). When an LSR knows the 
peer node is changed from LDP-MT capable to non-MT capable, it 
cleans up all the LSPs of all non-default MTs locally and 
initiates withdrawal of all label mapping for existing LSPs of all 
non-default MTs. Each side of the node sends a label release to 
its peer once it receives the label release messages even though 
each side has already cleaned up all the LSPs locally. 


o If an LSR does not support "Dynamic Capability Announcement", it 


MUST reset the session with its peer whenever the LSR changes its 
local capability with regards to supporting LDP MT. 
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4. 
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E. 


o If an LSR is changed from IGP-MT capable to non-MT capable, it may 
wait until the routes update to withdraw the FEC and release the 
label mapping for existing LSPs of a specific MT. 


Label Spaces 


The use of multiple topologies for LDP does not require different 
label spaces for each topology. An LSR can use the same label space 
for all MT FECs as for the default topology. 


Similarly, signaling for different topologies can and should be done 
within a single LDP session. 


Reserved MT-ID Values 
Certain MT topologies are assigned to serve predetermined purposes. 


In Section 9 ("IANA Considerations"), this document defines a new 
IANA registry "MPLS Multi-Topology Identifiers" to keep LDP MT-ID 
reserved values. 


If an LSR receives a FEC element with an "MT-ID" value that is 
"Unassigned" for future use (and not IANA allocated yet), the LSR 
MUST abort the processing of the FEC element and SHOULD send a 
notification message with status code "Invalid Topology ID" to the 
sender. 


MT Applicability on FEC-Based Features 
Typed Wildcard FEC Element 


[RFC5918] extends base LDP and defines the Typed Wildcard FEC element 
framework. The Typed Wildcard FEC element can be used in any LDP 
message to specify a wildcard operation/action for a given type of 
FEC. 


The MT extensions defined in this document do not require any 
extension to procedures for the Typed Wildcard FEC element, and these 
procedures apply as is to MT wildcarding. The MT extensions, though, 
allow use of "MT IP" or "MT IPv6" in the Address Family field of the 
Typed Wildcard FEC element in order to use wildcard operations in the 
context of a given topology. The use of MT-scoped address family 
also allows us to specify MT-ID in these operations. 


The defined format in Section 4.1 ("Typed Wildcard FEC element") 
allows an LSR to perform wildcard FEC operations under the scope of a 
topology. If an LSR wishes to perform a wildcard operation that 
applies to all topologies, it can use a "Wildcard Topology" MT-ID. 
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For example, upon local de-configuration of a topology "x", an LSR 
may send a typed wildcard Label Withdraw message with MT-ID "x" to 
withdraw all its labels from the peer that advertised under the scope 
of topology "x". Additionally, upon a global configuration change, 
an LSR may send a typed wildcard Label Withdraw message with the 
MT-ID set to "Wildcard Topology" to withdraw all its labels under all 
topologies from the peer. 


4.2. Signaling LDP Label Advertisement Completion 


[RFC5919] specifies extensions and procedures for an LDP speaker to 
signal its convergence for a given FEC type towards a peer. The 
procedures defined in [RFC5919] apply as they are to an MT FEC 
element. This allows an LDP speaker to signal its IP convergence 
using Typed Wildcard FEC element, and its MT IP convergence per 
topology using a MT Typed Wildcard FEC element. 


4.3. LSP Ping 


[RFC4379] defines procedures to detect data-plane failures in MPLS 
LSPs via LSP ping. That specification defines a "Target FEC Stack" 
TLV that describes the FEC stack being tested. This TLV is sent in 
an MPLS Echo Request message towards the LSP’s egress LSR and is 
forwarded along the same data path as other packets belonging to the 
FEC. 


"Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 
different FEC types. Section 3.2 of [RFC4379] defines the Sub-Types 
and format of the FEC. To support LSP ping for MT LDP LSPs, this 
document defines the following extensions to [RFC4379]. 

4.3.1. New FEC Sub-Types 
We define two new FEC types for LSP ping: 
o MT LDP IPv4 FEC 


o MT LDP IPv6 FEC 


We also define the following new sub-types for sub-TLVs to specify 
these FECs in the "Target FEC Stack" TLV of [RFC4379]: 


Sub-Type Length Value Field 
31 8 MT LDP IPv4 prefix 
32 20 MT LDP IPv6 prefix 


Figure 6: New Sub-Types for Sub-TLVs 
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The rules and procedures of using these sub-TLVs in an MPLS echo 
request message are the same as defined for LDP IPv4/IPv6 FEC sub-TLV 
types in [RFC4379]. 


4.3.2. MT LDP IPv4 FEC Sub-TLV 


The format of the "MT LDP IPv4 FEC" sub-TLV to be used in a "Target 
FEC Stack" [RFC4379] is: 


0 al 2 3 
01234567890123456789012345678901 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type = 31 (MT LDP IPv4 FEC) | Length = 8 | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv4 prefix | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Prefix Length | MBZ | MT-ID | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 


+— + — +— + 


Figure 7: MT LDP IPv4 FEC Sub-TLV 


The format of this sub-TLV is similar to the LDP IPv4 FEC sub-TLV as 


defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix 
Length" fields, this new sub-TLV also specifies the MT-ID (Multi- 
Topology ID). The Length for this sub-TLV is 5. 


The term "Must Be Zero" (MBZ) is used in object descriptions for 
reserved fields. These fields MUST be set to zero when sent and 
ignored on receipt. 
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4.3.3. MT LDP IPv6 FEC Sub-TLV 


The format of the "MT LDP IPv6 FEC" sub-TLV to be used in a "Target 
FEC Stack" [RFC4379] is: 


0 1 2 3 

01234567890123456789012345678<9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type = 32 (MT LDP IPv6 FEC) | Length = 20 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IPv6 prefix | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Prefix Length | MBZ | MT-ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 8: MT LDP IPv6 FEC Sub-TLV 


The format of this sub-TLV is similar to the LDP IPv6 FEC sub-TLV as 


defined in [RFC4379]. In addition to the "IPv6 prefix" and "Prefix 
Length" fields, this new sub-TLV also specifies the MT-ID (Multi- 
Topology ID). The Length for this sub-TLV is 17. 

4.3.4. Operation Considerations 


To detect data-plane failures using LSP ping for a specific topology, 
the router will initiate an LSP ping request with the target FEC 
stack TLV containing the LDP MT IP Prefix Sub-TLV in the Echo Request 
packet. The Echo Request packet is sent with the label bound to the 
IP Prefix in the topology. Once the Echo Request packet reaches the 
target router, it will process the packet and perform checks for the 
LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described 
in [RFC4379] and respond according to the processing rules in 
[RFC4379]. For the case that the LSP ping with return path is not 
specified, the reply packet must go through the default topology 
instead of the topology where the Echo Request goes through. 


It should be noted that the existing MIB modules for an MPLS LSR 
[RFC3813] and MPLS LDP managed objects [RFC3815] do not provide the 
necessary information to support the extensions in this document. 

For example, the absence of the MT-ID as an index into the MIB 
modules means that there is no way to disambiguate different topology 
instances. 
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Error Handling 


The extensions defined in this document utilize the existing LDP 
error handling defined in [RFC5036]. If an LSR receives an error 
notification from a peer for a session, it terminates the LDP session 
by closing the TCP transport connection for the session and 
discarding all multi-topology label mappings learned via the session. 


1. MT Error Notification for Invalid Topology ID 


An LSR should respond with an "Invalid Topology ID" status code in 
the LDP Notification message when it receives an LDP message with a 
FEC element specifying an MT-ID that is not locally known or not 
supported. The LSR MUST also discard the entire message before 
sending the Notification message. 


Backwards Compatibility 

The MPLS-MT solution is backwards compatible with existing LDP 
enhancements defined in [RFC5036], including message authenticity, 
integrity of message, and topology loop detection. 

The legacy node that does not support MT should not receive any 
MT-related LDP messages. In case bad things happen, according to 
[RFC5036], processing of such messages should be aborted. 

MPLS Forwarding in MT 


Although forwarding is out of the scope of this document, we include 
some forwarding consideration for informational purposes here. 


The specified signaling mechanisms allow all the topologies to share 
the platform-specific label space. This feature allows the existing 
data-plane techniques to be used. Also, there is no way for the data 
plane to associate a received packet with any one topology, meaning 
that topology-specific label spaces cannot be used. 


Security Considerations 


The use of MT over existing MPLS solutions does not offer any 
Specific security benefit. 


General LDP communication security threats and how these may be 
mitigated are described in [RFC5036]; these threats include: 


o spoofing 


o privacy 
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o denial of service 


For further discussion regarding possible LDP communication threats 
and mitigation techniques, see [RFC5920]. 


9. IANA Considerations 


This document introduces the following new protocol elements, which 
have been assigned by IANA: 


o New LDP Capability TLV: "Multi-Topology Capability" TLV (0x050C) 
from the LDP Parameters registry "TLV Type Name Space". 


o New Status Code: "Invalid Topology ID" (0x00000031) from the LDP 
Parameters registry "Status Code Name Space"). 


Registry: 
Range/Value Description 
0x00000031 Invalid Topology ID 


Figure 9: New Code Point for LDP Multi-Topology Extensions 


o New address families under the IANA registry "Address Family 


Numbers": 
Number Description 
29 MT IP: Multi-Topology IP version 4 
30 MT IPv6: Multi-Topology IP version 6 


Figure 10: Address Family Numbers 


Zhao, et al. Standards Track [Page 15] 


RFC 7307 LDP Multi-Topology Extensions July 2014 


o New registry "MPLS Multi-Topology Identifiers". 


This is a registry of the "Multiprotocol Label Switching 
Architecture (MPLS)" category. 


The initial registrations and allocation policies for this 
registry are: 


Range/Value Purpose Reference 
0 Default/standard topology REC 7307 
1 IPv4 in-band management RFC 7307 
2 IPv6 routing topology RFC 7307 
3 IPv4 multicast topology RFC 7307 
4 IPv6 multicast topology RFC 7307 
5 IPv6 in-band management RFC 7307 
6-3995 Unassigned for future IGP topologies RFC 7307 
Assigned by Standards Action RFC 7307 
3996-4095 Experimental RFC 7307 
4096-65534 Unassigned for MPLS topologies RFC 7307 
Assigned by Standards Action 
65535 Wildcard Topology RFC 7307 


Figure 11: MPLS Multi-Topology Identifier Registry 


o New Sub-TLV Types for LSP ping: The following new sub-type values 
under TLV type 1 (Target FEC Stack) have been registered from the 
"Sub-TLVs for TLV Types 1, 16, and 21" sub-registry within the 
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 
Ping Parameters" registry. 


Sub-Type Value Field 
31 MT LDP IPv4 prefix 
32 MT LDP IPv6 prefix 


Figure 12: New Sub-TLV Types for LSP Ping 
As highlighted at the end of Section 3.4 ("IGP MT-ID Mapping and 


Translation"), a new document will be created to detail the policy 
and process for allocating new MT-ID values. 
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10. 


10 


10. 


10. 


10. 


10. 


Manageability Considerations 
1. Control of Function and Policy 


There are capabilities that should be configurable to enable good 
manageability. One such example is to allow that the LDP Multi- 
Topology capability be enabled or disabled. It is assumed that the 
mapping of the LDP MT-ID and IGP MT-ID is manually configured on 
every router by default. If an automatic mapping between IGP MT-IDs 
and LDP MT-IDs is needed, there must be explicit configuration to do 
SO. 


.2. Information and Data Models 


Any extensions that may be required for existing MIBs are beyond the 
scope of this document. 


3. Liveness Detection and Monitoring 


Mechanisms defined in this document do not imply any new liveness 
detection and monitoring requirements. 


4. Verify Correct Operations 


In order to debug an LDP-MT-enabled network, it may be necessary to 
associate between the LDP label advertisement and the IGP routing 
advertisement. In this case, the user MUST understand the mapping 
mechanism to convert the IGP MT-ID to the LDP MT-ID. The method and 
type of mapping mechanism is out of the scope of this document. 


5. Requirements on Other Protocols 


If the LDP MT-ID has an implicit dependency on IGP MT-ID, then the 
corresponding IGP MT features will need to be supported. 


6. Impact on Network Operations 


Mechanisms defined in this document do not have any impact on network 
operations. 
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